Since this is considered an optional practice, do you think we should also add a parameter to the constructor to configure whether it's enabled or not?

@iansan5653 that's reasonable! How do you feel about opting-into each key individually?

type OptionalNavigationKeys = "Home" | "End"

// ...
optionalNavigationKeys: OptionalNavigationKeys[]

Hmm, I generally like the idea but I think there's never a case where you should enable one and not the other - if a user presses Home and it works, they will also expect End to work. If this tool is intended to enforce (or at least encourage) a11y best practices, I think it's OK if we limit flexibility in favor of enforcing the expected behavior.

Do you have an idea for what the constructor argument name should be? Is a third positional Boolean argument sufficient, or is it time to accept a third argument as an Object with a configuration key? I'm happy to implement in either style.

Actually, now that I look at the spec itself, maybe this isn't the correct behavior? It says (emphasis added):

Home (Optional): Either moves focus to and selects the first option or, if the combobox is editable, returns focus to the combobox and places the cursor on the first character.
End (Optional): Either moves focus to the last option or, if the combobox is editable, returns focus to the combobox and places the cursor after the last character.

In this case, the combobox is always editable (a non-editable combobox is essentially the same as an HTML <select> element) so these keys should actually return focus to the input and move the cursor. I think it might be incorrect to use these keys to move focus to the first/last option in an editable combobox.

I'm admittedly not 100% sure if that phrasing really means that if the combobox is editable, it's wrong to move focus to the first/last option.

Sorry for the back and forth on this - comboboxes are complicated 😅.

To answer your question, if we do decide to implement this, I think an optional config object would be the best route.

I've rebased this change and caught up to the latest main.

@keithamus Thank you for granting me CI permissions!

Is this change something the team is interested in supporting?

I agree with the last comment @iansan5653 raised; while the home/end keys offer useful shortcuts they should not change the behaviour while the input is focused. Can we ensure that this is the case with tests?